The present invention relates, in general, to multithreaded programming, and more specifically to identifying lock granularization opportunities using static analysis.
Some programming languages, such as, for example, java, provide for multi-threaded programming. This is exploited by most application development projects. Due to the introduction of multi-threading, an application developer must anticipate concurrent access to shared data. In order to make code thread-safe, it is common to synchronize all the instance methods on the “this” object (i.e., the “current” object, the one whose method is being executed). Several instance methods may exist which need to be synchronized as they access different sets of variables in different methods, which (though technically correct) can lead to bottlenecks as the application is scaled up. As an example, the following scenario will result in contention issues when the application is scaled up:
code block:public class Connection {........private long F1;private int F2;........public void updateTimeStamp( ) {long uses, switches, maxUses, maxSwitches;..../* Start of Code block B1 */synchronized(this) { // LOCKED ON CONNECTION instance, POSSIBLEBOTTLENECK if (uses != this.F1) {  switches = ++(this.F2); } uses = ++(this.F1);} //end of synchronization code block/* End of Code block B1 */....} // end of updateTimeStamp method} // public class Connection
The consequence of instance level locking is contention (threads will be held up from executing a piece of code due to the lock being held). The above code (synchronized on Connection object) will result in contention with numerous threads waiting for the Connection instance with the current thread executing the updateTimeStamp function. This problem can be seen when the application is scaled up to run on a multi-processor/core machine, such as an eight-way quad core machine.
As shown above, the piece of code where the variables F1 and F2 are accessed is synchronized on the Connection object. The Connection class also has more methods that have code synchronized on the ‘this’ object which do not access either F1 or F2. Therefore, locking on the Connection instance is inefficient as it blocks all other operations on the Connection object leading to a scalability bottleneck. Additionally, already existing applications may not have been developed with a futuristic view of scaling up. In an era of multi-cores, existing code may need to be rewritten to match the demands of increased loads due to scaling up the hardware.